If new temporary identities are created for the secure communication, how will paid relays with npub whitelists allow the messages to be published?

Unfortunately, you can either avoid using relay servers with npub restrictions for messaging with more advanced cryptographic features, or stick to the original NIP-04 which lacks both forward secrecy and deniability. Temporary identities can also be set to publish messages to relay servers without npub restrictions.

If new temporary identities are created for the secure communication, how will paid relays with npub whitelists allow the messages to be published?

they can use the AUTH protocol or a simple "auth" tag. npub whitelists are not really a good way to do things.

this is basically the same as NIP-59, except less general purpose

In the draft NIP-59, the first request is sent from and signed by Alice's permanent identity key, thus is basically undeniable. In order to keep deniability, sending messages from one's permanent identity should be avoided, while mentioning one's permanent identity from a message sent from a temporary identity is totally deniable.

in NIP-59 all messages are sent using an ephemeral public key. only the recipient can decrypt and prove identity. i think there are 2 NIP-59's. this is the one im talking about.

As shown in the latest draft NIP-59, the kind 4 message wrapped inside the kind 1059 message seems still signed by the sender's permanent identity, making it hardly deniable.

it's encrypted, so only the recipient can see it. that's the "wrapped" part. in your protocol bob can prove the temp id belonged to alice, for example. it's the same level of protection. only the recipient can prove the sender. if you want true deniability, just roll a new identity. otherwise the recipient can always prove.

in your protocol bob can prove the temp id belonged to alice

but unlike signature, bob cannot prove it to third party.

he can if he leaks his private key. signing a message with a shared secret is cool. you can even do it simply. just generate a shared secret, and sign a regular nostr message with (hash(shared-secret)*priv) as the private key. bob can get a DM of this kind at any time, and there's no need to dance back and forth. instead he can just verify the protocol was followed - know who sent it to him, even subscribe to it.... but not prove it without leaking the PK. then you don't even have to change nip04 (44) that much. a client who doesn't know this protocol will see it as an untrusted DM. a client that knows it will see it as a trusted DM.

he can if he leaks his private key. signing a message with a shared secret is cool. you can even do it simply. just generate a shared secret, and sign a regular nostr message with (hash(shared-secret)*priv) as the private key. bob can get a DM of this kind at any time, and there's no need to dance back and forth. instead he can just verify the protocol was followed - know who sent it to him, even subscribe to it.... but not prove it without leaking the PK. then you don't even have to change nip04 (44) that much. a client who doesn't know this protocol will see it as an untrusted DM. a client that knows it will see it as a trusted DM.

If Bob leaks his private key, Alice can say that anyone holding Bob's private key can forge such a message, so how can they prove the temp id belongs to Alice?

bob can prove it belongs to Alice because he has the signed message from her proving it came from her.

MAC is different from signature. Because Bob can also generate the shared secret and MAC the message with the same shared secret as Alice, he cannot prove to others that the message is MAC'ked by Alice instead of himself, which is the basic point of deniability.

ok, i see. this is equivalent to "signing the message with (a hash of) the shared secret" instead of signing it with the ephemeral key. that saves a step, gets you a fixed author field which can be useful, reduces the message size and doesn't introduce new validation on the part of the client. of course that points to a problem with both these ideas... how does bob know it's not from himself?

if he loads this up on a new nostr client... he'll have no idea what he wrote or what alice wrote. i guess that's ok? i mean, he'll have the "p" tag in the outer envelope... but either one of them could have put it there.

alice says "you told me that i should give you $50 not $60" and showing bob a forged message with her "p" tag on it... looking like it came from bob. i mean, it's kindof like caller-id at that point. easy to forge, but not everyone knows that, so some people fall for it.

this is equivalent to "signing the message with (a hash of) the shared secret" instead of signing it with the ephemeral key.

In order to verify a MAC, one should regenerate the MAC to compare, so different from signature, anyone who can verify a MAC can also regenerate ("forge") it.

alice says "you told me that i should give you $50 not $60" and showing bob a forged message with her "p" tag on it... looking like it came from bob. i mean, it's kindof like caller-id at that point. easy to forge, but not everyone knows that, so some people fall for it.

The "deniable temporary identity exchange protocol" is only used to exchange temporary identities. It is not designed for literal messages. After exchanging temporary identities, users are free to transport literal messages via whatever protocol they like, probably with stronger deniability where they can be sure that a message comes from their peer while unable to prove to others, like Vault1317, or OTRv4. (the method mentioned above was originally from OTRv3)

is only used to exchange temporary identities

ok, so all the messages should be marked as "kind ephemeral", where they get deleted after a certain amount of time. if i spin up a new client... i've lost alice's temp id, and need to re-establish it. i still suspect that the fact that it's forgeable should very boldly proclaimed in any nip. nostr clients rely heavily on proofs / signature validation, and knowing that a particular identity claimed to be alice might actually be "bob pretending to be alice to fool alice"... is a thing that they need to watch out for. in general, it seems useful.

then again, i still feel that the gift-wrap (59), which full hides metadata, is enough. no need to do a live/hot exchange of id's. have you looked at it? does it get you what you want?

As shown in the latest draft NIP-59, the kind 4 message wrapped inside the kind 1059 message seems still signed by the sender's permanent identity, making it hardly deniable.

NIP-59 is trying to solve different problems, while NIP-1317 only provides the deniability. The question here is more like whether Nostr community is interested in having deniability as an option in the long-run.

you can easily sign inner message with the shared secret, instead signing with the private key - providing the same deniability, and the same level of proof (could only be from yourself or from the other person). then we can use the same protocol and have optional deniability without a new layer.

can do the same for non-gift wrapped dm's - which gets you both deniability and metatadata hiding, and no new validation mechanisms.

or you can tweak your privkey with a shared secret. which gets you weaker deniability (bob can prove it's from alice, but only if he leaks his private key to the person he is proving it to) but is better for stateless systems (no possibility of forgery).

all are useful options.

you can easily sign inner message with the shared secret, instead signing with the private key

Cryptographically, how? Unlike the private key, the shared secret is not a scalar, let alone the notation for the recipient to know it is "signed with a shared secret between who and whom".

you can easily sign inner message with the shared secret, instead signing with the private key

Cryptographically, how? Unlike the private key, the shared secret is not a scalar, let alone the notation for the recipient to know it is "signed with a shared secret between who and whom".

you can just use the x coordinate or, to be safe, the hash of the x coordinate. now you have a secure, shared scalar, and you have the deniability - without the problem of being able to follow the conversation at all. easy enough to include sender in the envelope. nostr clients are generally stateless, and preserving this seems important.

you can modify nip-44 so that the outer message is signed this way, and the encrypted content contatins {a: author: c: content).

now you have OTRv3-style deniability (shared secret is the only proof of sender) and metadata hiding without interactivity.

ok, i see. this is equivalent to "signing the message with (a hash of) the shared secret" instead of signing it with the ephemeral key.

You always mix up signature and MAC, in which signature is fundamentally undeniable, while MAC is deniable.

nostr clients are generally stateless, and preserving this seems important.

That is why forward secrecy has seldom been concerned in Nostr and it doesn't make sense for modern cryptography engineering without forward secrecy.

then again, i still feel that the gift-wrap (59), which full hides metadata, is enough. no need to do a live/hot exchange of id's. have you looked at it? does it get you what you want?

It's one of reasons why NIP-59 is not enough for us.

I'm not mixing anything up You have to read what I wrote very carefully

there's no fundamental difference between a message authentication and a signature if both use the shared secret as the identifier

The advantage of using a signature is that you don't have to perform multiple authentications to get the same fully deniable result

I'm not mixing anything up You have to read what I wrote very carefully

there's no fundamental difference between a message authentication and a signature if both use the shared secret as the identifier

The advantage of using a signature is that you don't have to perform multiple authentications to get the same fully deniable result

Your understanding of cryptography reflected from your replies proves how far NIP-59 is beyond our consideration.

there's no fundamental difference between a message authentication and a signature if both use the shared secret as the identifier

Just pass by and interrupt for a moment. ;-)

Message authentication and signature schemes are two distinct cryptographic techniques that serve different purposes.

Message authentication schemes are used to verify the authenticity of a message, ensuring that it has not been tampered with or altered in transit. They typically use a shared secret key between the sender and recipient to generate a MAC that is sent along with the message. The recipient can then use the same shared secret key to verify the MAC and confirm the message's integrity.

On the other hand, signature schemes are used to provide non-repudiation, meaning that the sender cannot deny having sent a message. Signature schemes are typically used in scenarios where the authenticity and integrity of a message need to be guaranteed, and the sender needs to be held accountable for the message's contents.

While both message authentication and signature schemes may use a shared secret as part of their cryptographic operations, they serve different purposes and have distinct security properties. Therefore, it is not accurate to claim that there is no fundamental difference between the two if they use the shared secret as the identifier.